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Defusing a binary bomb with gdb 
- Part1 


This series of posts will show you how we can defuse a binary bomb. So what's a 
binary bomb? 


“A "binary bomb" is a Linux executable C program that consists of six 
"phases." Each phase expects the student to enter a particular string on 
stdin. If the student enters the expected string, then that phase is 
"defused." Otherwise the bomb "explodes" by printing "BOOM!!!". The 
goal for the students is to defuse as many phases as possible.” 


I found this type of bomb in the website for the excellent book “Computer 


The basic tools necessary to defuse such bomb are gdb and objdump . gdb 

is a debugger which we will use to inspect the program as werunit. objdump is 
a tool to disassemble object files so we can see the actual instructions that the 
computer is executing. 


This series is not intended to be a tutorial about gdb specially because it was 
my first time using it. 


Enough of that, let's start having some fun. After extracting the tarball we are 
left with: 


$ ls -l 

total 36 

—rwxr-xr-x 1 carlos carlos 26406 Jun 9 15:41 bomb 
-rw-r--r-- 1 carlos carlos 4069 Jun 9 15:41 bomb.c 
—rw-rw-r-- 1 carlos carlos 49 Jun 9 15:46 README 


Looking at bomb.c we see a bunch of comments and how everything is setup. 
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You can pass a file as argument to avoid typing every time the correct input for 
already defused phases. 


Next we need to take a look at the bomb executable which is binary data so we 
won't see anything interesting if we open it using $EDITOR . That's why we need 
objdump to disassemble this executable. 


$ objdump -d bomb > bomb.s 


If we take a look at the first few lines of this new file we see: 


bomb: file format elf64-x86-64 


Disassembly of section .init: 


0000000000400ac® <_init>: 


400acO: 48 83 ec 08 sub $0x8,%rsp 

400ac4: e8 f3 01 00 00 callq 4@@cbc <call_gmon_start> 
400ac9: 48 83 c4 08 add $0x8,%rsp 

400acd: c3 retq 


That is what an ELF file looks like when disassembled. Let's look at the main 
function then: 


0000000000400da0 <main>: 


400da0: 53 push ‘%rbx 
400dal1: 83 ff 01 cmp $0x1,%edi 
400da4: 75 10 jne 40Qdb6 <main+0x16> 


400da6: 48 8b 05 9b 29 20 00 mov Q@x20299b(%rip) ,%rax 
# 603748 <stdin@@GLIBC_2.2.5> 

400dad: 48 89 05 b4 29 20 00 mov %rax,@x2029b4(%rip) 
# 603768 <infile> 


400db4: eb 63 jmp 400e19 <main+0x79> 
40Qdb6: 48 89 f3 mov %rsi,%*rbx 

400db9: 83 ff 02 cmp $Ox2,%edi 

400dbc: 75 3a jne 400df8 <main+0x58> 
40Qdbe: 48 8b 7e 08 mov Ox8(%rsi) ,%rdi 
400@dc2: be b4 22 40 00 mov $0x4022b4,%sesi 
400dc7: e8 44 fe ff ff callq 400c10 <fopen@plt> 


40@dcc: 48 89 @5 95 29 20 00 mov %rax,0x202995(%rip) 
# 603768 <infile> 
400dd3: 48 85 cO test %rax,%*rax 
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400dd6: 75 41 jne 400e19 <main+0x79> 
400dd8: 48 8b 4b 08 mov x8 (%rbx) ,%rcx 

400ddc: 48 8b 13 mov %rbx) ,%rdx 

40O0ddf: be b6 22 40 00 mov $0x4022b6,%esi 

400de4: bf 01 00 00 00 mov $0x1,%edi 

400de9: e8 12 fe ff ff callq 400c00 <__printf_chk@plt> 
40Qdee: bf 08 0@ 00 00 mov $0x8, sedi 

400df3: e8 28 fe ff ff callq 40@c20 <exit@plt> 
400df8: 48 8b 16 mov %rsi) ,%*rdx 

40Qdfb: be d3 22 40 00 mov $0x4022d3,%eSi 

400e00: bf 01 00 00 00 mov $0x1,%edi 

400e05: b8 00 00 00 00 mov $0xO, seax 

400e0a: e8 f1 fd ff ff callq 400c00 <__printf_chk@plt> 
400e0Ff : bf 08 0@ 00 00 mov $0x8, sedi 

400e14: e8 07 fe ff ff callq 40@c20 <exit@plt> 
400e19: e8 84 05 00 00 callq 40@13a2 <initialize_bomb> 
400ele: bf 38 23 40 00 mov $0x402338,%edi 

400e23: e8 e8 fc ff ff callq 400b10 <puts@plt> 
400e28: bf 78 23 40 00 mov $0x402378,%edi 

400e2d: e8 de fc ff ff callq 400b10 <puts@plt> 
400e32: e8 67 06 00 00 callq 40149e <read_line> 
400e37: 48 89 c7 mov %rax,%*rd1i 

400e3a: e8 al 00 00 00 callq 4@Q@ee@ <phase_1> 

400e3Ff: e8 80 07 00 00 callq 4015c4 <phase_defused> 


I didn't paste the entire function since it's big enough and we are not concerned 
about the other phases yet. 


Before we start analyzing the function we need to understand the structure of 
each line. Let's take the following line as example: 


40Qdb6: 48 89 f3 mov %rsi,%*rbx 


We can break this line into three sections: 


e 40Q0db6 : the address of the code we are looking at. 
e 48 89 f3 : the encoded instruction. 


e mov %rsi,%rbx : the decoded instruction. 


The first few lines in the main function correspond to the C code that checks 
whether or not we passed a file as argument to the program. Skipping those 
lines we start to see the fun part: 
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400e19: e8 84 05 00 00 callq 40@13a2 <initialize_bomb> 


This line says that the function initialize_bomb should be called. The 
correspoding line in the C file is the following: 


/* Do all sorts of secret stuff that makes the bomb harder to defuse. 
*/ 
initialize_bomb(); 


So let's jump tothe initialize_bomb function. 


Q0000000004013a2 <initialize_bomb>: 


4013a2: 48 83 ec 08 sub $0x8,%rsp 

4013a6: be aQ@ 12 40 00 mov $0x4012a0,%esi 
4013ab: bf 02 0@ 00 00 mov $0x2,%edi 

4013b0: e8 db f7 ff ff callq 400b90 <signal@plt> 
4013b5: 48 83 c4 08 add $0x8,%rsp 

4013b9: c3 retq 


Inspecting the values don't reveal anything interesting. Let's move on. The next 
few lines after initialize_bomb inthe main function correspond to the 
following lines in the C file: 


printf("Welcome to my fiendish little bomb. You have 6 phases with 
\n" ) : 
printf("which to blow yourself up. Have a nice day!\n"); 


/* Hmm... Six phases must be more secure than one phase! x*/ 
input = read_line(); /* Get input */ 
phase_1(input) ; /* Run the phase */ 


So they print the messages and read the input. Then it's time to defuse the first 
phase. 


400e3a: e8 al 00 00 00 callq 4@Q@ee@ <phase_1> 


Again, this calls the function phase_1 located at 0x40Qee0 . Let's see what 
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the first phase looks like: 


0000000000400ee0 <phase_1>: 


400ee0: 48 83 ec 08 sub $0x8,%rsp 

400ee4: be 00 24 40 00 mov $0x402400,%esi 

400ee9: e8 4a 04 00 00 callq 401338 <strings_not_equal> 
400eee: 85 c@ test %eax , S6CAX 

400efO: 74 @5 je 400ef7 <phase_1+@x17> 
400ef2: e8 43 05 00 00 callq 40143a <explode_bomb> 
400ef7: 48 83 c4 08 add $0x8, srsp 

400efb: c3 retq 


Notice on @x400ee4 thatthe value @x402400 is copied to the register esi . 
The esi register is usually used as the register for the second argument of a 
function that will be called later. In our case such function is called right after 
the mov instruction. You might then ask: where is the first argument? The first 
argument is usually placed in the edi register which in this case will be the 
string we provided as input. If you take a look at the main function you will 
see: 


400e32: e8 67 06 00 00 callq 40149e <read_line> 
400e37: 48 89 c7 mov %rax,%*rd1i 
400e3a: e8 al 00 00 00 callq 4@@ee@ <phase_1> 


The return value (storedin rax ) ofthe read_line function has been placed 
inthe rdi register( edi isa 32-bit registerand rdi is the equivalent 64-bit 
register) and will be used as the first argument for the function that will be 
called next which in this case is phase_1 . And that is exactly what the C code is 


doing: 
/* Hmm... Six phases must be more secure than one phase! x*/ 
input = read_line(); /* Get input */ 
phase_1(input) ; /* Run the phase */ 


Ok, back to the phase_1 function. We now know what the arguments given to 
strings_not_equal are and after executing such function there is a test to 
check the result: 
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400ee9: e€8 4a 04 00 00 callq 401338 <strings_not_equal> 
4@@eee: 85 cO test %eax , 6eaX 

400ef@: 74 05 je 400ef7 <phase_1+0x17> 
400ef2: e8 43 05 00 00 callq 40143a <explode_bomb> 


The test instruction will perform a bitwise AND operation between its 
operands and set the appropriate flags on register eflags .The je 

instruction is a conditional jump instruction that jumps to the specified location 
only if the previous comparison set the ZF (Zero Flag) to 1 inthe eflags 
register. 


Sothe test instruction willset ZF to 1 onlywhenwehave @ in eax 
which only happens when strings_not_equal returns 0 . (Examining 

strings_not_equal doesn't reveal anything interesting, it's exactly what you 
expect from a function with such name. It returns 1 if both arguments are 
not equaland @ otherwise.) 


If the strings are not equal the conditional jump will not be performed and then 
the next line will be executed which will explode the bomb. If the strings are 
equal wejump to 0x400eef7 andreturnto main: 


400ef0: 74 05 je 400ef7 <phase_1+0x17> 
400ef2: e8 43 05 00 00 callq 40143a <explode_bomb> 
400ef7: 48 83 c4 08 add $0x8, %rsp 

400efb: c3 retq 


Ok, we now know that the first phase requires us to provide a string that we 
don't know. How we are going to discover which string is this? We need to start 
executing the program. But in this case instead of executing like you usually do 
with other programs we will run it with gdb . gdb will help us to inspect the 
values and find out what is this mysterious string. 


$ gdb bomb 


The line above starts gdb withthe bomb program attached to it so we can 
execute the bomb and inspect the values, set breakpoints, etc. In this case we 
have already done most of the work by only examining the assembly code and 
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we know that the mysterious string is located at address @x402400 (when it 
was loaded on register esi ataddress @x40Qee4 ). To see what is the value of 
it we can simply ask gdb to print the value at the desired address and treat it 


as sequence of char : 


(gdb) p (char *) 0x402400 
$1 = 0x402400 "Border relations with Canada have never been better." 


And voila! We have the string we need. 


Now executing the program: 


(gdb) run 

Starting program: /home/carlos/Downloads/bomb/bomb 

Welcome to my fiendish little bomb. You have 6 phases with 
which to blow yourself up. Have a nice day! 


Then entering the full string we will see that phase 1 was defused: 


Border relations with Canada have never been better. 
Phase 1 defused. How about the next one? 
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Defusing a binary bomb with gdb 
- Part 2 


19 Nov 2015 


This post is part of a series where I show how to defuse a binary bomb by 
reading assembly code and using gdb . You might want to read the first 
part if you haven't yet. 


After defusing the first phase we were challenged to defuse the next one: 


Border relations with Canada have never been better. 
Phase 1 defused. How about the next one? 


The corresponding assembly code inthe main function is the following: 


400e3a: e€8 al 00 00 00 callq 40Q0ee0 <phase_1> 
400e3f: e8 80 07 00 00 callq 4015c4 <phase_defused> 
400e44: bf a8 23 40 00 mov $0x4023a8, sedi 

400e49: e8 c2 fc ff ff callq 400b10 <puts@plt> 
400e4e: e€8 4b 06 00 00 callq 40149e <read_line> 
400e53: 48 89 c7 mov %rax,%*rd1i 

400e56: e8 al 00 00 00 callq 400efc <phase_2> 
400e5b: e8 64 07 00 00 callq 4015c4 <phase_defused> 


As we can see (at @x400e53 ) it puts our inputin the rdi register to be used 
as the first argument to phase_2 which will be called by the next instruction. 
Just like you would imagine that the actual C code is doing: 


printf("Phase 1 defused. How about the next one?\n"); 


/* The second phase is harder. No one will ever figure out 
* how to defuse this... */ 

input = read_line(); 

phase_2(input); 

phase_defused(); 
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So what phase_2 looks like? 


Q000000000400efc <phase _2>: 


400efc: 55 push ‘%rbp 

400efd: 53 push %rbx 

400efe: 48 83 ec 28 sub $0x28,%rsp 

400fO2: 48 89 e6 mov %rsp,%rsi 

400fO5: e8 52 05 00 00 callq 40145c <read_six_numbers> 
400f0a: 83 3c 24 Q@1 cmpl  $0x1, (%rsp) 

400f0e: 74 20 je 400f30 <phase_2+0x34> 
400f10: e8 25 05 00 00 callq 40143a <explode_bomb> 
400f15: eb 19 jmp 400f30 <phase_2+0x34> 
400f17: 8b 43 fc mov -0x4(%rbx) ,%eax 
400f1la: Q1 cO add %eax , *eAX 

400fic: 39 @3 cmp %eax, (S%srbx) 

400file: 74 @5 je 400f25 <phase_2+@x29> 
400f20: e8 15 05 00 00 callq 40143a <explode_bomb> 
400f25: 48 83 c3 04 add $0x4, %Srbx 

400f29: 48 39 eb cmp %rbp, %rbx 

400f2c: 75 e9 jne 400f17 <phase_2+0x1b> 
400f2e: eb Qc jmp 400f3c <phase_2+0x40> 
400f30: 48 8d 5c 24 04 lea Ox4(%rsp) ,%*rbx 
400f35: 48 8d 6c 24 18 lea 0x18(%rsp) ,%rbp 
400f3a: eb db jmp 400f17 <phase_2+0x1b> 
400f3c: 48 83 c4 28 add $0x28,%rsp 

400f40: 5b pop %rbx 

400f41: 5d pop Ssrbp 

400f42: c3 retq 


Right off the bat we can see that this phase is expecting us to enter six numbers: 


400f05: e8 52 05 00 00 callq 40145c <read_six_numbers> 


That can be confirmed by inspecting read_six_numbers function: 


Q00000000040145c <read_six_numbers>: 


40145c: 48 83 ec 18 sub $0x18,%rsp 
401460: 48 89 f2 mov %rsi,%*rdx 
401463: 48 8d 4e 04 lea Qx4(%rsi) ,%rcx 
401467: 48 8d 46 14 lea 0x14(%rsi) ,%rax 
40146b: 48 89 44 24 08 mov %Srax,Q@x8(%srsp) 
401470: 48 8d 46 10 lea 0x10(%rsi) ,%rax 
401474: 48 89 04 24 mov Srax, (%rsp) 
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401478: 4c 8d 4e Oc lea Oxc(%rsi) ,%r9 

40147c: 4c 8d 46 08 lea Qx8(%rsi),%r8 

401480: be c3 25 40 00 mov $0x4025c3,%eSi 

401485: b8 00 00 00 00 mov $0x@,%eax 

40148a: e8 61 f7 ff ff callq 4@@bf®@ <__isoc99_sscanf@pl 
t> 

40148f : 83 f8 05 cmp $0x5,%eax 

401492: 7f 05 jg 401499 <read_six_numbers+0 
x3d> 

401494: e8 al ff ff ff callq 40143a <explode_bomb> 

401499: 48 83 c4 18 add $0x18,%rsp 

40149d: c3 retq 


At 0x40148a wesee that it calls sscanf which has the following purpose: 


#include <stdio.h> 


int scanf(const char xformat, .«1:); 
int fscanf(FILE xstream, const char xformat, ...); 
int sscanf(const char x*str, const char xformat, .1:); 


The scanf() family of functions scans input according to format as 
described below. This format may contain conversion specifications; the 
results from such conversions, if any, are stored in the locations pointed 
to by the pointer arguments that follow format . Each pointer argument 
must be of a type that is appropriate for the value returned by the 
corresponding conversion specification. 


Following the same idea we used on phase 1 we can confirm this function does 
exactly what its name suggests. On @x401480 something is stored at esi to 
be used as the second argument for sscanf which as seen above is the 
expected format for our input. 


401480: be c3 25 40 00 mov $0x4025c3,%eSi 


Then on gdb we can print the value just like we did on phase_1 : 


(gdb) p (char *) 0x4@25c3 
$1 = 0x4025c3 "%d %d %d %d %d %d" 
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read_six_numbers then checks if we typed at least six numbers, if we did it 
returns, otherwise the bomb explodes. 


Back at phase_2 function we find that our first number must be 1 
(comparison at 0x400f0a ) otherwise the bomb will explode right away: 


400f05: e8 52 05 00 00 callq 40145c <read_six_numbers> 
400f@a: 83 3c 24 Q1 cmpl $0x1,(%rsp) 

400f@e: 74 20 je 400f30 <phase_2+0x34> 
400f10: e8 25 05 00 00 callq 40143a <explode_bomb> 


After confirming that our first number was 1 it goesto @x400f30 : 


400f30: 48 8d 5c 24 04 lea @x4(%rsp) ,%*rbx 
400f35: 48 8d 6c 24 18 lea 0x18 (%rsp),%rbp 
400f3a: eb db jmp 400f17 <phase_2+0x1b> 


On 0x400f30 the address of the next number is stored on rbx andon 
0x400f35 rbp gets the address right after the address of the last number 
parsed by sscanf on read_six_numbers . 


(gdb) p $rsp+0x18 

$2 = (void «) Ox7fffffffddd8 
(gdb) p $rsp 

$3 = (void «) Ox7fffffffddcd 


Considering just the low order byte: 0xd8 - @xc@ = 0x18 . Which is decimal 
24 .Each int takes four bytes so the memory structure looks like the image 
below which explains why rbp holds the address after the sixth number: 
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HigH ORD BYTES ALE: OKSIFFFFEFEDD 


Oxe0 ADORESS (Low orver gre) 


pe Pee [a fs De] vane 
Then the execution will continue on 0x4Q0Qf17 : 
400f17: 8b 43 fc mov -0x4(%rbx) ,%eax 
40@fla: 01 cO add %eax , %eAX 
400fic: 39 @3 cmp %eax, (%rbx) 
400fle: 74 05 je 400f25 <phase_2+0x29> 
400f20: e8 15 05 00 00 callq 40143a <explode_bomb> 


On 0x400f17 the previous number is copied into eax then the next 

instruction duplicates this value on eax which is then compared with our 

second number. If they are equal the function will continue execution at 
0x400f25 , otherwise you know what. 


On 0x400f25 the pointer goes to the next number. Next it checks if the pointer 
passed the last number which means all six numbers were checked. If it didn't it 
goes back to @x400f17 to check the next number and if all numbers were 
already checked it willjump to 0x400f3c that willthen return to main . 


400f25: 48 83 c3 04 add $0x4,%rbx 
400f29: 48 39 eb cmp %rbp,%*rbx 
400f2c: 75 e9 jne 400f17 <phase_2+0x1b> 
400f2e: eb Oc jmp 400f3c <phase_2+0x40> 


Checking numbers, moving pointers forward, jumping back and forth suggests 
that we are dealing with aloop. Assuming p_ isa pointer to the first number, 
the loop in phase_2 might look like the following: 


for (int *x = p+ 1; x != (p + 6); x++) { 
int previous = *(x - 1); 
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if (*x != previous * 2) 
explode_bomb(); 


Alright, now we have an idea of what the next five numbers should be. They 
have to be the double of the previous number. If we start at 1 thenextis 2 , 
the nextis 4 andso on. This might ring a bell, doesn't it? Our input must be 
the first six powers of 2 : 


e 20 S74 
“oso 
e 2°=4 
e 23-8 
© 24-16 
e 29=32 


After entering the six numbers we see that we defused the second phase: 


Phase 1 defused. How about the next one? 
12 4 8 16 32 
That's number 2. Keep going! 
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Defusing a binary bomb with gdb 
- Part 3 


03 Dec 2015 


This post is part of a series where I show how to defuse a binary bomb by 


reading assembly code and using gdb . You might want to read the 


other parts if you haven't yet. 


Following the usual process, after defusing the second phase we were 


challenged to defuse the third one: 


Welcome to my fiendish little bomb. You have 6 phases with 
which to blow yourself up. Have a nice day! 

Border relations with Canada have never been better. 

Phase 1 defused. How about the next one? 

12 4 8 16 32 
That's number 2. 


Keep going! 


The corresponding instructions on main are the following: 


40@e5b: 
400e60: 
400e65: 
400e6a: 
400e6f : 
400e72: 


e8 
bf 
e8 
e8 
48 
e8 


64 
ed 
a6 
2f 
89 
CC 


Q7 
22 
fc 
06 
c7 
00 


00 00 
40 00 
ff ff 
00 00 


00 00 


callq 
mov 
callq 
callq 
mov 
callq 


The code for phase_3 is the following: 


Q000000000400f43 <phase_3>: 
400f43: 
400f47: 
400f4c: 
400f51: 
400f56: 
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48 83 ec 18 sub 
48 8d 4c 24 Oc lea 
48 8d 54 24 08 lea 
be cf 25 40 00 mov 
b8 Q@@ 00 00 20 mov 


4015c4 <phase_defused> 
$0x4022ed, sedi 

400b10 <puts@plt> 
40149e <read_line> 
%rax,%*rd1i 

400f43 <phase_3> 


$0x18,%rsp 
Oxc(%rsp) , %*rcx 
Q@x8(%rsp) , %*rdx 
$O0x4025cf,%sesi 
$0xO,%eax 
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4Q0f5b: 
t> 
400T6O: 
400Tf63: 
400Tf65: 
400f6a: 
4Q0f6f: 
400f71: 
4Q0f75: 
400f7c: 
400f81: 
400f83: 
400f88: 
400f8a: 
4Q00f8F: 
400f91: 
400T96: 
400f98: 
400f9d: 
4Q00f9Ff: 
400fa4: 
400fa6: 
40Qfab: 
400fad: 
400fb2: 
400fb7: 
400Fb9: 
400fbe: 
400fc2: 
400fc4: 
400Ffc9: 
400fcd: 


On 0x400f51 wesee that some value is stored on esi , eax gets initialized 


90 fc 


f8 @1 


44 24 


tf 


andthen sscanf_ is called. 


If you don't remember from the previous phase, sscanf isa function that 
scans input according to some format that is given as argument to it. Such 
format must be what's stored on esi . 
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Tf 


00 


(gdb) p (char *) 0x4025cf 


$1 = Qx4025c 


So we must enter 2 integers. This could also be confirmed by looking at the 
following instructions which compare if we entered more than one integer to 
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"Sed Sol" 


callq 4@@bf®@ <__isoc99_sscanf@pl 


cmp 
jg 
callq 
cmp l 
ja 
mov 
jmpq 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
mov 
jmp 
callq 
mov 
jmp 
mov 
cmp 
je 
callq 
add 
retq 


$0x1, %eax 

400f6a <phase_3+0x27> 
40143a <explode_bomb> 
$0x7 , Ox8(%rsp) 

400fad <phase_3+@x6a> 
Ox8(%rsp) ,%eax 
*0x402470(,%rax,8) 
$Oxcf , seax 

400fbe <phase_3+@x7b> 
$0x2c3,%eax 

400fbe <phase_3+0x7b> 
$0x100,xeax 

400fbe <phase_3+@x7b> 
$0x185, eax 

400fbe <phase_3+@x7b> 
$Oxce, seax 

400fbe <phase_3+@x7b> 
$0x2aa, %eax 

400fbe <phase_3+@x7b> 
$0x147, xeax 

400fbe <phase_3+0x7b> 
40143a <explode_bomb> 
$0x0,%eax 

400fbe <phase_3+0x7b> 
$0x137,%*eax 

Oxc(%rsp) ,%eax 

400fc9 <phase_3+0x86> 
40143a <explode_bomb> 
$0x18,%rsp 


2/6 


5/29/2016 Defusing a binary bomb with gdb - Part 3 - carlosgaldino 


continue executing the third phase otherwise the bomb will explode. 


400f60: 83 f8 01 cmp $0x1, seax 
400f63: 7f @5 jg 400f6a <phase_3+0x27> 
400f65: e8 dQ 04 00 00 callq 40143a <explode_bomb> 


You might be wondering how sscanf_ got its first argument which is the string 
used as source for scanning the desired values. As explained in previous posts 
the first argument to functions is usually placed on register _rdi and any 
instruction can interact with any register, the same way you would interact with 
a global variable in a program. If you look at 0x40@e6f inthe main function 
the string we enter as input for phase_3 iscopiedto rdi to then be used as 
the first argument to sscanf : 


40@e6f: 48 89 c7 mov %rax,%*rdi 
400e72: e8 cc 00 00 00 callq 400f43 <phase_3> 


Ok, continuing the execution of phase_3 the next instruction to be executed is 
located at @x400f6a (assuming we entered two integers, of course). At that 
location the program compare the first integer we gave as input. It should be 
less than or equalto 7 otherwise the execution will continue on @x40Qfad . 


400f6a: 83 7c 24 08 07 cmpl $0x7,0x8(%rsp) 
400fo6f: LE. 736 ja 400fad <phase_3+@x6a> 


And at 0x40@fad we know what's expecting us: 


400fad: e8 88 04 00 00 callq 40143a <explode_bomb> 


Assuming we entered an integer smaller than or equal to 7 the program 
continues: 


400f71: 8b 44 24 08 mov Q@x8(%rsp) ,%eax 
400f75: ff 24 c5 70 24 40 00 jmpq +*0x402470(,%rax,8) 
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The first instruction above will copy the first integer to eax and then on the 
second instruction jump to a location based on this integer. Let's pretend we 
entered @ as our first integer. In that case the program would jump to the 
address location stored at 0x402470 . The rule for calculating the address is the 
following: 


*«(%rax * 8 + Qx402470) 


That is: multiply the value stored on rax by 8 ,additto 0x402470 and then 
read the value stored at the result location. Inspecting the value on 0x402470 
we see that's the address of the next line: 


(gdb) x 0x402470 
0x402470: 0x00400fF7c 


So entering @ as our first number would execute the following instructions: 


400Ff7c: b8 cf 0@ 00 00 mov $Oxcf , eax 
400f81: eb 3b jmp 400fbe <phase_3+@x7b> 


This stores @xcf (decimal 207)o0n eax andthenjumpsto 0x400fbe that 
does the following: 


400fbe: 3b 44 24 Oc cmp Oxc(%rsp) ,%eax 
400fc2: 74 @5 je 400fc9 <phase_3+0x86> 
400fc4: e8 71 04 00 00 callq 40143a <explode_bomb> 
400fc9: 48 83 c4 18 add $0x18,%rsp 

400fcd: c3 retq 


In other words, on @x400fbe the program will compare our second number to 
what was stored on eax ,in this imaginary case of entering @ as our first 
number it would then compare if our second number was 207 . If that's the 
case it means we defused phase_3 : 


@ 207 
Halfway there! 
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So that's it?! Pretty simple, right? But what about all the other instructions 
above 400fbe ? What are their purpose? 


All these instructions are part of a switch statement. That's why on 

Qx400f75 the address that the program will jump to will be calculated based 
on what we entered, opposed to what happened before when the location to 
jump to was hardcoded in the instruction itself!. Taking a closer look at the 
instructions before @x400fbe we see that they all follow the same pattern: 
store some value on eax andthenjumpto 0x400fbe to compare our second 
number to this value stored on eax .So phase_3 has more than one answer, 
let's see all of them: 


(gdb) x/8g 0x402470 

Qx402470: OxQQQ0Q0Q0B00400F7C Ox00Q0000000400Fb9 
Qx402480: QxQ000000000400FT83 20x0000000000400Ff8a 
Qx402490: QxQ000000000400T91 0x0000000000400F98 
Qx4024a0: OxQQQQOQOQGOO400TIF 0x0000000000400F ab 


The command above tells gdb to examine the memory starting at address 
0x402470 and display eight blocks ( 8 in the command) of eight bytes ( g in 
the command, g asin giant words). The output then shows two values per line 
so we can build a table relating the first input number, the address the switch 

jumps to and what should be the second input number: 


First Address Expected second Expected second 
input to jump input number input number 
number to (hex) (decimal) 

O Qx400F7Cc Oxcf 207 

i Qx400fb9 Qx137 311 

2 @x400f83 @x2c3 707 

3 Qx400f8a @x100 256 

4 @x400f91 @x185 389 

: Qx400f98 Q@xce 206 

6 Ox400f9F Q@x2aa 682 
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7 0x400fa6 Qx147 327 


Any of the combinations above will work. 


Notes 


1. In this case using PC-relative addressing. 
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- Part 4 


This post is part of a series where I show how to defuse a binary bomb by 
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reading assembly code and using gdb . You might want to read 


part if you haven't yet. 


We are back on defusing the fourth phase of the binary bomb. 


The code for phase_4 is the following: 


Q00000000040100c <phase _4>: 
40100c: 
401010: 
401015: 
40101a: 
40101f: 
401024: 


401029: 
40102c: 
40102e: 
401033: 
401035: 
40103a: 
40103f: 
401044: 
401048: 
40104d: 
40104f: 
401051: 
401056: 
401058: 
40105d: 
401061: 


Exactly as happened on phase 3 we can see that this phase is expecting two 
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48 
48 
48 
be 
b8 
eg 


83 
8d 
8d 
cf 
00 
c7 


f8 
Q7 
7C 
@5 
00 
Qe 
00 
7C 
81 


ec 
4c 
54 
25 
00 
fb 


Q2 
24 
04 
00 
00 
24 
Tf 
24 


03 
c4 


18 
24 


00 


00 


sub 
lea 
lea 
mov 
mov 
callq 


cmp 
jne 
cmp l 
jbe 
callq 
mov 
mov 
mov 
callq 
test 
jne 
cmp l 
je 
callq 
add 
retq 


$0x18,%rsp 
Oxc(%rsp) ,%*rcx 
Q@x8(%rsp) , %*rdx 
$0x4025cf ,%esi 
$0x0, eax 


4Q00bfO@ <__isoc99_sscanf@pl 


$O0x2,%eax 

401035 <phase_4+@x29> 
$0xe, Ox8(%rsp) 

40103a <phase_4+@x2e> 
40143a <explode_bomb> 
$Oxe, %edx 

$O0x0,%eSi 

Q@x8(%rsp) ,%edi 

400fce <func4> 
%eaXx , 6CAX 

401058 <phase_4+@x4c> 
$0x0,Oxc(%rsp) 

40105d <phase_4+@x51> 
40143a <explode_bomb> 
$0x18,%rsp 
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integers as input. On @x40101a the same format used before is stored on esi 
which is then used by sscanf on 0x401024 . 


(gdb) p (char *) 0x4025cf 
$1 = Ox4025cf "%Sd %d" 


On 0x401029 wecan also confirm that if we enter more than 2 integers the 
code will jump to @x401035 that calls explode_bomb : 


401029: 83 f8 02 cmp $Ox2 ,%*eax 
40102c: 75 7 jne 401035 <phase_4+@x29> 


So which exact numbers should we enter? It must be a number that is less than 
15: 


40102e: 83 7c 24 08 @e cmp l $0xe, Ox8(%rsp) 
401033: 76 @5 jbe 40103a <phase_4+@x2e> 
401035: e8 00 04 00 00 callq 40143a <explode_bomb> 


cmpl compares @xe_ which is 14 to the first integer we entered for this 
phase. Then jbe ("jump below or equal") will skip exploding the bomb if the 
value is less than or equal to 14. 


After that we can see that some setup is done before calling a new function, 


func4 : 
40103a: ba 0e 00 00 00 mov $Oxe, sedx 
40103f: be 00 00 00 00 mov $0x®,%eSi 
401044: 8b 7c 24 08 mov Ox8(%rsp) ,%*edi 
401048: e8 81 ff ff ff callq 4@0@fce <func4> 


edi is usually used as the register to hold the first argument, esi holds the 
second and edx holds the third argument. The first argument is the first 
number we provided, the second and third are @ and 14 , respectively. 


Let's take a look at func4 : 
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Q000000000400fce <func4>: 
400fce: 48 83 ec 08 
400fd2: 89 da 
400fd4: 29 fO 
400fd6: 89 cl 
400fd8: c1 e9 1f 
400fdb: Q1 c8 
400fdd: d1 f8 
40ofdf: 8d Oc 30 
400fe2: 39 f9 
400fe4: Je Oc 
400fe6: 8d 51 ff 
400fe9: e8 eQ ff ff ff 
400fee: Q1 cO 
400ffo: eb 15 
400ff2: b8 00 00 00 00 
400ff7: 39 f9 
40off9: 7d Qc 
400ffb: 8d 71 01 
400ffe: e8 cb ff ff ff 
401003: 8d 44 00 01 
401007: 48 83 c4 08 
40100b: c3 


sub 
mov 
sub 
mov 
shr 
add 
sar 
lea 
cmp 
jle 
lea 
callq 
add 
jmp 
mov 
cmp 
jge 
lea 
callq 
lea 
add 
retq 


$0x8, %rsp 

%edx , *eax 

%eS1,6eaXx 

%eaX , SECX 
$Ox1f , sECx 
%ECX , 6CaX 

%eaXx 

%rax,%rsi,1) ,%ecx 
%edi,%*eCx 

400ff2 <func4+0x24> 
-Ox1(%rcx) ,%edx 
400fce <func4> 
%eax , 6CaX 

401007 <func4+0x39> 
$0x0,%eax 

%edi,%*eCx 

401007 <func4+0x39> 
Qx1(%rcx) ,%esi 
400fce <func4> 
@x1(%rax,%rax,1),%eax 
$0x8, %rsp 


Looking at the first few instructions we can try to write what exactly is 


happening with the arguments that were given to this function. The instructions 


until @x400fe2 are actually doing something like the following: 


int func4(int a, int b, int c) { 
int x = c — b; // @x4@O0fd2 and @x400fd4 
= X >> 31; // @x400fd6 and Ox400fd8 


int y 

x = xX + y; // 0x400fdb 
xX = xX >> 1; // 0x400fdd 
y=x +b; // 0x400TdT 


Then itcompares y with a (our first input number for this phase) and if y 


<= a itwilljumpto 0x400ff2 . Otherwise it calls func4 again but this time 
c willbe y - 1 (setat 0x400fe6 ).Soon 0x400fe9 wecan think of the 


invocation as: 


func4(a, b, y - 1); 
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After calling it you can see that 0x400fee will double the result from that 
"inner" invocation ( eax holds the return value from that execution) and then 
jump to @x401007 which cleanups the stack frame for this invocation. So the 
result from this recursive call is actually: 


return 2 * func4(a, b, y - 1); 


If y >= a the code will continue execution on 0x400ff2 . At that line it sets 

the possible result as @ and then compares the same y with a again. This 

time if y >= a itjumpsto 0x401007 andreturns Q , that's why eax got 

the value @ bythe instruction before that. If y < a then func4 willbe 

called again but in this case b willbe y + 1 (this assignment happens on 
Q0x400ffb ) and the following invocation happens on 0x400ffe : 


func4(a, y + 1, c); 


After returning from this recursive call the return value is set on 0x401003 
using the result from the recursive call so the result is actually: 


return 2 * func4(a, y + 1, c) + 1; 


With all this context we can now try to guess what exactly is going on with this 
function: 


int func4(int a, int b, int c) { 
int x =c -— b; 


int y = x >> 31; 
Y= ys 
X =X >> 13 
y=x +b; 
if .(y<=a): + 
if (y >= a) { 
return Q; 
} else { 
return 2 * func4(a, y + 1, c) + 1; 
; 
} else { 


return 2 * func4(a, b, y - 1); 
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Remember that the initial call to func4 is func4(ourFirstInputNumber, Q, 
14) andthat ourFirstInputNumber <= 14 . Let's try to see what happens if 


we input 1 as our first number: 


func4(1, @, 14) { 
int x = 14 -@; 
int y = 14 >> 31; 


x = 14 + Q; 
xX = 14 >> 1; 
y=7+20; 


Then we can see that func4 will be called bythe else clause of the first 
fi 


return 2 * func4(1, 0, 7 - 1); 


The first recursive call will then be: 


func4(1, @, 6) { 


int x = 6 - @; 
int y = 6 >> 31; 
X = 6 + Q; 

X =6>> 1; 
y=3 +0; 


Again the same branch will be taken: 


return 2 * func4(1, ®, 3 - 1); 


The execution will then be: 


func4(1, 0, 2) { 
int x =2 -9Q0; 
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This time y == 1 soboth if branches will be taken and @ will be returned 


from this recursive invocation. Remember that we invoked this function twice 


so the final result will be: 


return func4(1, @, 14); 


return 2 * func4(1, 0, 6); 
return 2 * func4(1, 0, 2); 


return Q; 


Since the last callto func4 returned @ the final result will also be @ and 


the execution will continue this time on phase_4 at 0x40104d : 


401048: 
40104d: 
40104f: 
401051: 
401056: 
401058: 
40105d: 
401061: 


eg 
85 
75 
83 
74 
e8 
48 
c3 


81 
c0 
Q7 
7C 
@5 
dd 
83 


teat 


24 Oc 00 


03 00 00 
c4 18 


callq 
test 
jne 
cmp l 
je 
callq 
add 
retq 


400fce <func4> 
%eaXx , 6CAX 

401058 <phase_4+@x4c> 
$0x0,Oxc(%rsp) 

40105d <phase_4+@x51> 
40143a <explode_bomb> 
$0x18,%rsp 


This line and the line below test whether or not the result of that func4 


invocation returned @ , if it did our first input is correct and execution 


continues at @x401051 . This instruction then simply checks if our second 


inputis @ and if itis the function returns and phase 4 is defused: 


1 0 


So you got that one. 


Try this one. 


We have something interesting here, remember that there are two checks about 


y and a ? The second check uses the jge instruction that checks whether 


the value is greater than or equal to (kind of obvious if you think about what 


ge might mean in the instruction name). The interesting fact here is that the 
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previous check also tested for equality with jle .So,if y <= a andthen you 
check whether y >= a there's only one case that would satisfy both conditions 


and thatis y == a .I'mnotsure ifthe compiler chose jge even though the 
code was written as if (y == a) orifthe code was actually written as if (y 
>= a). 


Another interesting thing about this phase is how the compiler manages the 
results of the recursive calls. Since eax is aregister the results of each 
recursive invocation will be available to the stack frame that invoked it and then 
it can simply be returned without saving the result in some other place. Also you 
see that after calling func4 again there's nothing managing the local variables 

x and y which is why they are also stored in registers instead of being saved 
inside each stack frame. 


An exercise left to the reader is trying to find the other possible solutions for this 
phase including one input that doesn't even call func4 recursively. Also try to 
see which numbers are invalid for this phase and the result that func4 returns 
when these numbers are used. 


Notes 


1. @x8(%rsp) and Qxc(%rsp) store both input numbers as local variables 
inthe phase_4 stack frame. e 
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Defusing a binary bomb with gdb 
- Part 5 


This post is part of a series where I show how to defuse a binary bomb by 


reading assembly code and using gdb . You might want to read 


part if you haven't yet. 


After defusing the fourth phase the program continues to the next phase: 


40@ea2: 


40Q@eaa: 


e8 f7 05 00 00 
40@ea7: 48 89 c7 
e8 b3 01 00 00 


callq 40149e <read_line> 
mov %rax,%*rdi 
callq 401062 <phase_5> 


The code for phase_5 is the following: 


0000000000401062 <phase_5>: 


401062: 
401063: 
401067: 
40106a: 
401071: 
401073: 
401078: 
40107a: 
40107f: 
401082: 
401084: 
401089: 
40108b: 
40108f : 
401092: 
401096: 
401099: 
4010a0: 
4010a4: 
4010a8: 
4010ac: 
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ec 
fb 
8b 
44 


02 
06 


Q3 


20 


04 


24 


00 


00 
03 
24 
bQ 
10 


Q1 
06 


25 28 00 


18 


00 


00 


24 40 00 


push 
sub 
mov 
mov 


mov 
xor 
callq 
cmp 

je 
callq 
jmp 
movzbl 
mov 
mov 
and 
movzbl 
mov 
add 
cmp 
jne 


%rbx 
$0x20,%rsp 
%rdi,%*rbx 
%FS:0x28,%rax 


%rax,0x18(%rsp) 
%eaXx , 6CAX 

40131b <string_length> 
$0x6,%eax 

4010d2 <phase_5+@x70> 
40143a <explode_bomb> 
401@d2 <phase_5+@x70> 
%rbx,%rax,1) ,%ecx 
%Cl, (%rsp) 

Srsp) ,%rdx 

$Oxf , %edx 
Qx4024b0(%rdx) , %edx 
%d1,0x10(%rsp,%rax,1) 
$O0x1,%rax 

$0x6, %rax 

40108b <phase_5+@x29> 
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4010ae: c6 44 24 16 00 movb $0x@,0x16(%rsp) 
4010b3: be 5e 24 40 00 mov $0x40245e, seSi 
4010b8: 48 8d 7c 24 10 lea 0x10(%srsp) ,%rdi 
4010bd: e8 76 02 00 00 callq 401338 <strings_not_equal> 
4010c2: 85 c@ test %eax , 6CAX 

4010c4: 74 13 je 4010d9 <phase_5+0x77> 
4010c6: e8 6f 03 00 00 callq 40143a <explode_bomb> 
4010cb: Of 1f 44 00 00 nopl  Qx@(%rax,%rax,1) 
4010d0: eb 07 jmp 4010d9 <phase_5+0x77> 
4010d2: b8 00 00 00 00 mov $0xO, seax 

4010d7: eb b2 jmp 40108b <phase_5+@x29> 
4010d9: 48 8b 44 24 18 mov 0x18 (%rsp) ,%rax 


4010de: 64 48 33 04 25 28 00 xor %FS:0x28,%rax 
4010e5: 0@ 00 


4010e7: 74 @5 je 401@ee <phase_5+@x8c> 

4010e9: e8 42 fa ff ff callq 4@0@b30 <__stack_chk_fail@p 
lt> 

4010ee: 48 83 c4 20 add $0x20,%rsp 

4010f2: 5b pop %rbx 

4010f3: c3 retq 


The first few lines setup the stack for this function and on 0x40106a_ the stack 


protector is setup. 


On 0x40107a anewfunction string_length is called to check the length of 
the input we gave to phase_5 . Remember that the argument for phase_5 is 
stored inthe rdi register and the same value is available when 
string_length is called. The input must be exactly six characters as shown by 
the comparison on 0x40107f . Ifthe input length is correct it then jumps to 
0x4010d2 thatsets rax to @ andthenjumpsto @x40108b to continue 
executing this phase. 


On 0x40108b the first byte from the input string is copied to ecx . Notice that 
at the start of this function the input string stored on rdi was copied to rbx 
at @x401067 . The instruction at @x40108b usesboth rbx and rax but 
since rax hasavalueof 0 the data address used as source will be solely the 
address stored on rbx . We can confirm it with: 


(gdb) p (char *) $rbx 
$1 = @x6038c0 <input_strings+32@> "input5" 


And to see each byte as hex: 
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(gdb) x/6xb $rbx 
@x6038c@ <input_strings+32Q>: @x69 @x6e Qx70 @x75 Qx74 
@x35 


Stepping to next instruction we can also confirm that the byte from the first 
character is stored on ecx : 


(gdb) i r $ecx 
ecx Q@x69 105 


@x69 is i inthe ASCII table. 


Then on the next two instructions this byte is copied to _rdx andon 

0x401096 a bitwise AND is performed against this byte. The value after the 
bitwise AND is then used as an offset to copy a value from some location to the 
same edx registeron 0x401099 . That same 1-byte value is then stored in a 
local variable on @x4010a0 . The next instruction increments rax which is 
then checked by the next instruction to see if this process was executed for all 
characters from our input. If the process wasn't performed for all characters it 
then jumps again to 0x40108b to read the next character and repeat the steps 
above. 


At the end of this process a local variable will hold a new string that is created 
by using our input characters as an offset to a mysterious string. 


If the process was executed for all characters it then prepares the arguments for 
the next function call, starting at 0x401@ae . This new string we're talking 
about will be used as an argument to the strings_not_equal function that 
we've seen before in this series. The other string that ours will be compared to is 
located at @x40245e as youcanseeon 0x4010b3 . 


After calling strings_not_equal the result will be tested on @x4010c2 andif 
they are equal the code will jump to the end of phase_5 at 0x4010d9 that will 
check if stack wasn't corrupted and return. If the strings are different you know 
what's going to happen. 


Now that we know the flow for this phase it's time to see which string our input 
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must produce. 


(gdb) p (char *) 0x40245e 
$2 = @x40245e "flyers" 


Now all that we need is to look at the intermediary string to see which are the 
offsets we need to input so that the final string will be flyers . 


(gdb) p (char *) 0x4024b0 
$3 = @x4024b0 <array> "maduiersnfotvbylSo you think you can stop the 
bomb with ctrl-c, do you?" 


Looking at the output above we can guess that the actual intermediary string 
must be just maduiersnfotvbyl . Looking at the position of each character we 
can then check that the correct offsets must be: 


letter offset 


f Ox9 
] oxf 
y oxe 
e Ox5 
r Ox6 
S OXx7 


So the answer is actually any sequence of characters which their byte 
representations end in 9FE567 . 


Considering just the printable characters from the ASCII table we can devise the 
following table: 


offset possible chars 
Ox9 JoIYiy 
oxf /?0_o0DEL 


oxe .>N%*%n~ 
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5/29/2016 
OX5 %5EUeu 
Ox6 &6FViV 
OX7 '7GWgw 


Any combination of a single char for each offset will defuse phase_5 . 


The sixth and final phase will be covered in the next post. 


Notes 


1. https://en.wikipedia.org/wiki/Buffer_overflow_protection © 
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Defusing a binary bomb with gdb 


- Part 6 


This post is part of a series where I show how to defuse a binary bomb by 


reading assembly code and using gdb . You might want to read 


part if you haven't yet. 


Here we are at the last phase. This is the most interesting phase so far. The code 
for phase_6 is the following: 


Q0000000004010f4 <phase_6>: 
4010f4: 41 56 
4010f6: 41 55 
4010f8: 41 54 
4010fa: 55 
4010fb: 53 
4010fc: 48 83 ec 50 
401100: 49 89 e5 
401103: 48 89 e6 
401106: e8 51 03 00 00 
40110b: 49 89 e6 


40110e: 41 bc 00 00 00 00 


401114: 4c 89 ed 
401117: 41 8b 45 00 
40111b: 83 e8 01 
40111e: 83 f8 @5 
401121: 76 05 

401123: e8 12 03 00 00 
401128: 41 83 c4 @1 
40112c: 41 83 fc 06 
401130: 74 21 

401132: 44 89 e3 
401135: 48 63 c3 
401138: 8b 04 84 
40113b: 39 45 00 
40113e: 75 @5 

401140: e8 f5 02 00 00 
401145: 83 c3 01 
401148: 83 fb 05 


push 
push 
push 
push 
push 
sub 
mov 
mov 
callq 
mov 
mov 
mov 
mov 
sub 
cmp 
jbe 
callq 
add 
cmp 
je 
mov 
movslq 
mov 
cmp 
jne 
callq 
add 
cmp 


%r14 

%r13 

%r12 

Ssrbp 

%rbx 

$0x50,%rsp 

Srsp,%*rl3 

%rsp,%rsi 

40145c <read_six_numbers> 
%rsp,%*rl4 

$0x0,%r12d 

%r13,%rbp 
Qx@(%r13) , %eax 
$0x1,%eax 

$0x5,%eax 

401128 <phase_6+0x34> 
40143a <explode_bomb> 
$0x1,%r12d 

$0x6,%r12d 

401153 <phase_6+@x5f> 
%r12d,%ebx 

%ebx, *rax 
%rsp,%rax,4) , %eax 
%eax, Ox0(%rbp) 

401145 <phase_6+@x51> 
40143a <explode_bomb> 
$0x1,%ebx 

$0x5,%ebx 
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40114b: 
40114d: 
401151: 
401153: 
401158: 
40115b: 
401160: 
401162: 
401164: 
401166: 
40116a: 
40116d: 
40116f: 
401174: 
401176: 
40117a: 
40117d: 
40117f: 
401181: 
401183: 
401188: 
40118d: 
401191: 
401195: 
401197: 
40119a: 
40119d: 
40119f: 
4011a4: 
4011a9: 
4Q11ab: 
4011b0: 
4011b5: 
4011ba: 
4011bd: 
4011cQ: 
4011c4: 
4011c8: 
4011cb: 
4011cd: 
4011d0: 
4011d2: 
4011d9: 
4011da: 
4011df: 
4011e3: 
4011e5: 
4011e7: 
4011e9: 
4011ee: 
4011f2: 
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Q2 
5b 
01 


04 


24 


00 


04 


00 


08 


60 
74 
04 
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00 
60 


24 


24 
24 


08 
08 


08 


00 
08 


00 
08 
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jle 401135 <phase_6+@x41> 
add $0x4,%r13 
jmp 401114 <phase_6+0x20> 


18 lea 0x18(%rsp) ,%rsi 
mov %r14,%rax 
00 mov $Ox7 , SCX 
mov %eCX, *edx 
sub (%rax) ,%edx 
mov %edx, (%rax) 
add $0x4,%rax 
cmp %rSi,%*rax 
jne 401160 <phase_6+@x6c> 
00 mov $O0x®@,%eSi 
jmp 401197 <phase_6+@xa3> 
mov x8 (%rdx) , %rdx 
add $0x1,%eax 
cmp %ECX , 6eaX 


jne 401176 <phase_6+0x82> 
jmp 401188 <phase_6+0x94> 


00 mov $0x6032d0,%edx 
20 mov %rdx,0x20(%rsp,%rsi,2) 
add $0x4,%rsi 
cmp $0x18,%rsi 
je 4011ab <phase_6+@xb7> 
mov %rsp,%rsi,1) ,%eCx 
cmp $O0x1,%eECX 
jle 401183 <phase_6+0x8f> 
00 mov $0x1, %eax 
00 mov $0x6032d0,%edx 
jmp 401176 <phase_6+0x82> 
20 mov Q@x20(%srsp) , %rbx 
28 lea 0x28 (%rsp) ,%rax 
50 lea Ox5O(S%rsp) ,%rsi 
mov %rbx,%*rcx 
mov %rax) ,%rdx 
mov %rdx, x8 (%rcx) 
add $0x8, %rax 
cmp %rSi,%*rax 
je 4011d2 <phase_6+@xde> 
mov %rdx,%*rCcx 


jmp 4011bd <phase_6+@xc9> 
00 20 20 movg $0x0,@x8(%rdx) 


00 mov $0x5, sebp 
mov x8 (%rbx) , %rax 
mov %rax) ,%e@ax 
cmp %eax, (S%rbx) 
jge 4Q1lee <phase_6+@xfa> 
00 callq 40143a <explode_bomb> 
mov x8 (%rbx) ,%rbx 


sub $0x1,%sebp 
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4011f5: 75 e8 jne 4011df <phase_6+@xeb> 
4011f7: 48 83 c4 50 add $0x50,%rsp 

4011fb: 5b pop %rbx 

4011fc: 5d pop %rbp 

4011fd: 41 5c pop %r12 

4011ff: 41 5d pop %r13 

401201: 41 5e pop %r14 

401203: c3 retq 


It's longer than the other phases and seems more complicated so we're going to 
break it in parts to explain what each part is doing. 


The first part we can look at is where the function initializes. It starts by saving 
some registers values because they are going to be used as local variables in this 
function, then making room for other local variables and then reading the input 
that will be used to defuse the phase. At @x401106 wecan see that the input 
for this phase must be six numbers: 


4010f4: 41 56 push %r14 

4010f6: 41 55 push %ri13 

4010f8: 41 54 push ‘%ri2 

4010fa: 55 push  %rbp 

4010fb: 53 push ‘%rbx 

4010fc: 48 83 ec 50 sub $0x50,%rsp 

401100: 49 89 e5 mov %rsp,%*rl3 

401103: 48 89 e6 mov %rSp,%*rsi 

401106: e8 51 03 00 00 callq 40145c <read_six_numbers> 
40110b: 49 89 e6 mov %rsp,%rl4 

40110e: 41 bc 00 00 00 00 mov $0x0,%r12d 

401114: 4c 89 ed mov %r13,%rbp 

401117: 41 8b 45 00 mov Qx@(%r13) ,%eax 
40111b: 83 e8 Q1 sub $0x1,%eax 

40111e: 83 f8 @5 cmp $0x5 , %eax 

401121: 76 05 jbe 401128 <phase_6+0x34> 
401123: e8 12 03 00 00 callq 40143a <explode_bomb> 


After reading the six numbers and placing the first one on rsp_ the code copies 
the address pointing to the first one into r14 then it sets up other variables 
and finally on @x40111e it checks whether or not the first number we provided 
is less than or equalto 6 . Howit did that? 


rsi is used to hold the second argument for a function call and prior to calling 
read_six_numbers (at @x401103 ) the address of rsp wascopiedto rsi 
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to be used by read_six_numbers . That's where our numbers were stored, in an 
array that starts at the address that ison rsi . This same address is also stored 
on rsp and r13 .Wecan look at the registers to see which address this is: 


(gdb) i rorsp rsi r13 


rsp Ox7ttfttftffdd6d0 Oaex7fffftfffdd6e 
rsi Ox7ftftftfffdd60 140737488346464 
r13 Ox7tttftfffdd60 140737488346464 


After returning from read_six_numbers this same address is stored on r14 
at 0x40110b andon @x40114 itisstoredon rbp as well. 


Then on 0x401117 the value stored in the address on 113 , our first number, 
is copied to eax and then the code checks if it is less than or equalto 6 . 


So now that we understand how the check was made, let's proceed to the next 


part: 
401128: 41 83 c4 Q1 add $0x1,%r12d 
40112c: 41 83 fc 06 cmp $0x6,%r12d 
401130: 74 21 je 401153 <phase_6+@x5f> 
401132: 44 89 e3 mov %r12d,%ebx 
401135: 48 63 c3 movslq %ebx,%rax 
401138: 8b 04 84 mov %rsp,%*rax,4) ,%eax 
40113b: 39 45 00 cmp %eax,0x0(%rbp) 
40113e: 75 05 jne 401145 <phase_6+@x51> 
401140: e8 f5 02 00 00 callq 40143a <explode_bomb> 


Remember that on line @x40110e theregister r12d storedthe value 0 so 
the first three lines are just for checking if the code already went through 6 
iterations. Let's continue on @x401132 where the new value of 112d (which 
is 1 for the first iteration) is copied into ebx which then is copied to rax by 
sign-extending from double word (4 bytes) to quad word (8 bytes) since ebx is 
a 32-bit register while rax is a 64-bit register. 


After that the next number we entered is checked against the first one. The 
second number is copied to eax by this instruction: 


401138: 8b 04 84 mov (%rsp,%rax,4) ,%eax 
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What this line actually does is: multiply by 4 the value on rax (1 since it 
came from r12d ) and add that value to value stored on rsp (the starting 
address of the array holding our input numbers). For the first iteration the 
resulting address will be: 


(gdb) x $rsp+$raxx*0x4 
Ox7fffffffdd64: 0x00000002 


The value stored at this resulting address will then be copied to eax . For the 
first iteration it means our second input number. 


Then our second value (on eax ) is compared to first one to see if they are not 
equal and jumps to the next part: 


401145: 83 c3 01 add $0x1,%ebx 
401148: 83 fb @5 cmp $0x5 , %eDx 
40114b: 7e e8 jle 401135 <phase_6+0x41> 
40114d: 49 83 c5 04 add $0x4,%r13 
401151: eb cl jmp 401114 <phase_6+0x20> 


The first three lines will check if we did this check for all six numbers which 

means we cannot input repeated numbers. After that,on @x40114d , r13 is 

changed to hold the address of the second input number by adding 4 bytes 

( sizeof(int) )tothe address r13 is currently storing. Then it goes back to 
@x401114 to do the same checks against the other numbers we provided. 


Now we know some facts about the expected input: 


e It must be six numbers; 
e They need to be less than or equal to 6 ; 
e They cannot repeat. 


Let's continue to see which other characteristics these numbers must have. 


After doing these initial checks the code will jump to 0x401153 : 


401153: 48 8d 74 24 18 lea @x18(%rsp),%*rsi 
401158: 4c 89 fQ mov %r14,%rax 
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40115b: b9 O7 00 00 00 mov $O0x7 , SCX 

401160: 89 ca mov %eECX, *edxX 

401162: 2b 10 sub %rax) ,%edx 

401164: 89 10 mov %edx, (%rax) 

401166: 48 83 c®@ 04 add $0x4,%rax 

40116a: 48 39 f@ cmp %rSi,%*rax 

40116d: 75 f1 jne 401160 <phase_6+@x6c> 
40116f: be 00 00 00 00 mov $O0xO,%seSi 

401174: eb 21 jmp 401197 <phase_6+0xa3> 


The first line of this part simply defines the address that means we iterated over 
all six numbers. The first number is stored on the address that rsp holds and 
the sixth number will be on $rsp + 0x14 (start address + offset of 5 int ). 


r14 also holds the address for the first number so it's going to be copied to 

rax on @x401158 to be used in this iteration. Then on the next two lines both 

ecx and edx storethevalue 7 . After the setup the actual iteration will start 
by first subtracting from edx the value stored by the addressin rax (our 
first number in the first iteration). At @x401164 the result of this subtraction 
will overwrite the value on rax andthenon @x401166 the code will move to 
the next int we provided, compare on 0@x40116d if we iterated over all six 
numbers and jump backto x401160 if we did not, otherwise get out of the 
loop and continue execution on 0x401197 . 


Let's simulate what happens after this loop is executed. Suppose we entered 1 

2 3 4 5 6 as our input numbers for this phase. Then after iterating in this loop 
our array will have the following new values: 6 5 4 3 2 1 . The loop just 
changes the all numbers in the array to be abs(n-7) . 


After exiting the loop we continue on 0x40@1197 which brings us to the next 


part in this phase: 
401176: 48 8b 52 08 mov Qx8(%rdx) , %rdx 
40117a: 83 cO 01 add $0x1,%eax 
40117d: 39 c8 cmp %ECX , SAX 
40117f: 75 f5 jne 401176 <phase_6+0x82> 
401181: eb 05 jmp 401188 <phase_6+0x94> 
401183: ba d@ 32 60 00 mov $0x6032d0,%edx 
401188: 48 89 54 74 20 mov %rdx,Ox20(%rsp,%rsi, 2) 
40118d: 48 83 c6 04 add $0x4,%rsi 
401191: 48 83 fe 18 cmp $0x18,%rsi 
401195: 74 14 je 4011ab <phase_6+@xb7> 
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401197: 8b Oc 34 mov (%rsp,%rsi,1),%ecx 
40119a: 83 f9 @1 cmp $0x1,%ECx 

40119d: 7e e4 jle 401183 <phase_6+0x8f> 
40119f: b8 01 00 00 00 mov $0x1,%eax 

4011a4: ba d@ 32 60 00 mov $0x6032d0,%edx 
4011a9: eb cb jmp 401176 <phase_6+0x82> 


Although the first line of this part is at @x401176 , execution actually starts at 
0x401197 . After executing this line ecx will hold the first number from our 
array because the value stored on rsi is @ (from 0x40116f ) and the 
instruction on @x401197 means: copy the value stored by the address of 
$rsix@x1 + $rsp to ecx . This operation clearly means it is part of some 
iteration and we can guess that rsi_ will be updated in the process to go over 
the other numbers in the array. 


401197: 8b Oc 34 mov %rsp,%*rsi,1) ,%ecx 
40119a: 83 f9 @1 cmp $0x1,%ECx 

40119d: 7e e4 jle 401183 <phase_6+0x8f> 
40119f: b8 01 00 00 00 mov $0x1,%eax 

4011a4: ba d@ 32 60 00 mov $0x6032d0,%edx 
4011a9: eb cb jmp 401176 <phase_6+0x82> 


If the current number on ecx is less than or equal to 1 the code will jump to 
0x401183 , otherwise it will jump to @x401176 . 


In the last part our array became: 6 5 4 3 2 1 .Sothe code will jump to 
Qx401176 . Let's see what happens there. 


401176: 48 8b 52 08 mov Qx8(%rdx) , %rdx 
40117a: 83 cO 01 add $0x1,%eax 

40117d: 39 c8 cmp %ECX , SAX 

40117f: 75 f5 jne 401176 <phase_6+0x82> 
401181: eb 05 jmp 401188 <phase_6+0x94> 


Notice that before jumping to @x401176 , the address @x6032d@ was stored 
on edx . Then the value stored after the first 8 bytes of this address will be 
copied to rdx on 0x401176 . After this operation, eax will be incremented 
and compared with ecx to then conditionally jump to another place in this 
part or againto 0x401176 . The initial value of eax inthiscaseis 1 that was 
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seton 0x40119f beforejumping to 0x401176 . ecx holdsthe value 6 so 
we go back to @x401176 and copy the value on $rdx + 0x8 to rdx , 
increment eax and check against ecx . 


The values on ecx and eax will match only after six iterations: in our 
example, ecx starts with 6 and eax with 1 . In this case before jumping 
to @x401188 , rdx will have whatever value is storedin $rdx + @x48 (six 
times adding x8 to the initial address and copying the value in the new 
address to rdx ). 


Then the code jumps to 0x401188 : 


401183: ba d@ 32 60 00 mov $0x6032d0,%edx 
401188: 48 89 54 74 20 mov %rdx,O0x20(%rsp,%rsi, 2) 
40118d: 48 83 c6 04 add $O0x4,%rsi 

401191: 48 83 fe 18 cmp $0x18,%rsi 

401195: 74 14 je 4011lab <phase_6+0xb7> 
401197: 8b Oc 34 mov %rsp,%*rsi,1) ,%ecx 
40119a: 83 f9 01 cmp $0x1,%ECxX 

40119d: 7e e4 jle 401183 <phase_6+0x8f> 
40119f: b8 01 00 00 00 mov $0x1,%eax 

4011a4: ba d@ 32 60 00 mov $0x6032d0,%edx 
4011a9: eb cb jmp 401176 <phase_6+0x82> 


At this line the address that rdx_ is holding will be copied to the address that 
results from: $rsix0x2 + $rsp + @x20. rsi is the index over the iteration 
that is going on: 


(gdb) ir rsi 
rsi Qx® QO 


Next, rsi isincremented by 4 ( sizeof(int) ) and compared against 
Qx18 to see if we iterated over all six numbers. If we did not then on 
Q@x401197 , ecx gets the next number from our array and the next iteration 

begins. 


Now that we know what this iteration is all about let's see what exactly is stored 
by the initial address on rdx : 
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(gdb) x 0x6032d0 
Q@x6032d@ <nodel>: Qx0000014c 


Huh, node1 , interesting name, right? Let's see what this address plus 8 bytes 
holds: 


(gdb) x 0x6032d0+0x8 
Q@x6032d8 <node1+8>: 0x006032e0 


Looking at what is on 0x6032e0 : 


(gdb) x 0x6032e0 
Q@x6032e@ <node2>: 0x000000a8 


Aha! That looks like a linked list. To see the address of node3 : 


(gdb) x 0x6032e0+0x8 
@x6032e8 <node2+8>: 0x006032FO 


And what node3 stores: 


(gdb) x *(@x6032e0+0x8) 
Qx6032f@ <node3>: Qx0000039c 


We have a linked list that holds an int value, the node identifier and the 
pointer to the next node, something like the following: 


struct node { 
int x; 
int i; 
struct node xnext; 


yt 


So when the code jumps to @x401188 , rdx will have the address of the value 
stored by node6 since ourarrayis 6 5 4 3 2 1 and it went through 
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@x401176 six times: 


(gdb) i r rdx 

rdx Qx603320 6304544 
(gdb) x 0x6032d0+0x48 

Qx603318 <node5+8>: 0x00603320 
(gdb) x $rdx 

Q@x603320 <node6é>: Qx@00001bb 


The address rdx_ holds, which stores the value 0x1bb , will be placed in the 
first position of a new array starting at $rsp + x20 . Since this code iterates 
over all six numbers, after executing this part for all numbers this new array will 
actually store the addresses holding the values that the corresponding node 
stores, based on our transformed input array. 


Explaining: from 0x401176 until @x401181 the code is looking for the 
corresponding node for the current iteration. On @x401188 the address of 
value x that the node holds is then copied to the current iteration index on the 
new array. Then the next iteration begins. 


Let's see what are the values that each node stores and their addresses. First we 
define a command to print the node values and move to the next node: 


define plist 

set var $n = $argQ 

while $n 

printf "nodexd (%p): value = %#.3x, next=%p\n", *($n+@x4), $n, x$n, 
*«($n+0x8) 

set var $n = *($n+®x8) 

end 
end 


Printing the values: 


(gdb) plist @x6032d0 

node1 (Qx6032d0): value = Qx14c, next=0x6032e0 
node2 (0x6032e0): value = Qx0a8, next=0x6032fO 
node3 (Qx6032f@): value = Qx39c, next=0x603300 
node4 (0x603300): value = @x2b3, next=0x603310 
node5 (0x603310): value = Oxldd, next=0x603320 
node6 (@x603320): value = Qx1bb, next=(nil) 
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After iterating over the six numbers using our input array which was 
transformed into 6 5 4 3 2 1 the newarray (starting at $rsp + @x20 ) will 
hold the addresses of x in the following order: node6 node5 node4 node3 
node2 nodel . 
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(gdb) x/6gx $rsp+0@x20 
Ox7fffffFFdd80: Ox0000000000603320 20x0000000000603310 
Ox7ffffFFFdd90: Ox0000000000603300 0x00000000006032fO 
Ox7fffffffdda®@: Ox00000000006032e0 20x00000000006032d0 


After creating this new array the code continues execution at @x4011lab which 


is the next part: 


4011ab: 
4011b0: 
4011b5: 
4011ba: 
4011bd: 
4011c0: 
4011c4: 
4011c8: 
4011cb: 
4011cd: 
4011d0: 
4011d2: 
4011d9: 
4011da: 
4011df: 
4011e3: 
4011e5: 
4011e7: 
4011e9: 
4011ee: 
4011f2: 
4011f5: 


At the first line of this part rbx gets the value of the first element of the new 
array which is the address of x for node6 .Inthenext line rax gets the 
second element of the new array and in the third line _rsi gets an address that 
is Just past the last element of this new array, most likely to check later if we 
iterated over the entire new array. 
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48 
48 
48 
48 
48 
48 
48 
48 
74 


5c 
44 
74 
d9 
10 
51 
cO 
1) 


di 


42 


00 
43 


Q2 
5b 
Q1 


00 00 00 


00 


00 


mov 
lea 
lea 
mov 
mov 
mov 
add 
cmp 
je 
mov 
jmp 
movq 


mov 
mov 
mov 
cmp 
jge 
callq 
mov 
sub 
jne 


Q@x20(%rsp) ,%rbx 
Q@x28(%rsp) ,%rax 
0x50(%rsp) ,%rsi 
%rbx,%*rcx 

%rax) ,%rdx 
%rdx,@x8(%rcx) 
$0x8 , *rax 

%rsi,%6rax 

4011d2 <phase_6+@xde> 
%rdx,%*rcx 

4011bd <phase_6+@xc9> 
$0xO, 0x8 (%rdx) 


$0x5,%ebp 

x8 (%rbx) , %rax 

%rax) ,%e@ax 

%eax, (%rbx) 

4011lee <phase_6+0xfa> 
40143a <explode_bomb> 
0x8 (%rbx) ,%rbx 
$0x1,%ebp 

4011df <phase_6+@xeb> 
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On 0x4011ba , rcx will hold the value of the first element of the new array, 
then rdx will get the second value and in the next line, 0x4011c@ , this value 
will be copied to $rcx + @x8 . Let's back it up for a minute and see the values 
in both registers after executing the instruction at @x4011c0 : 


(gdb) i r rex rdx 
rcx @x603320 6304544 
rdx Qx603310 6304528 


$rcx + @x8 is the address that holds the pointer to the next element of the 
list and after executing @x4011c0 it will point to the value that rdx is 
storing: 


(gdb) x $rcx+0x8 
Qx603328 <node6+8>: 0x0000000000603310 


After that,on @x4011c4 the next value from the new array is placed in_ rax 
for the next iteration which is checked against rsi in the next line and the 
process repeats. At the end of itthe next pointer foreach node will be 
changed according to the values of the new array. As we've seen above the new 
array has the following values: 


(gdb) x/6gx $rsp+0x20 

Ox7fffffFfdd80: Ox0000000000603320 20x0000000000603310 
Ox7ffffFFFdd9O: Ox0000000000603300 0x00000000006032fO 
Ox7fffffffdda®@: Ox00000000006032e0 20x00000000006032d0 


These values correspond to node6 node5 node4 node3 node2 node1 so after 

the iteration above the pointers will be changed to reflect this order. We can 

confirm it with our plist command after executing the instruction on 
@x4011d2 : 


(gdb) plist 0x603320 

node6 (0x603320): value = Oxlbb, next=0x603310 
node5 (0x603310): value = Oxldd, next=0x603300 
node4 (0x603300): value = Qx2b3, next=0x6032f0 
node3 (Qx6032f@): value = Qx39c, next=0x6032e0 
node2 (Qx6032e0): value = Qx0a8, next=0x6032d0 
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node1 (@x6032d0@): value = 0x14c, next=(nil) 


With the initial input of 1 2 3 4 5 6 the code has reversed the list. Note that 
I now used the address of node6 as the starting address for plist since that 
is the order from the array located at $rsp + @x20 . Also notice that on 

Q@x4011d2 the next pointer for the last iteration receives the NULL value 
and in our case itis node1->next . 


4011da: bd 05 00 00 00 mov $0x5,%sebp 

4011df: 48 8b 43 08 mov Qx8(%rbx) , %rax 
4011e3: 8b 00 mov %rax) ,%eax 

4011e5: 39 @3 cmp %eax, (%rbx) 

4011e7: 7d 05 jge 4011lee <phase_6+0xfa> 
4011e9: e8 4c 02 00 00 callq 40143a <explode_bomb> 
401lee: 48 8b 5b 08 mov @x8(%rbx) , Srbx 
4011f2: 83 ed 01 sub $0x1,%ebp 

4011f5: 75 e8 jne 4011df <phase_6+@xeb> 


Now that the list was changed the execution continues at @x4011da_by storing 
the value 5 in ebp . Then the address of value x of the next node is stored 
on rax and then in the next line the actual x valueisstoredon eax (32-bit 
register since we're dealing with int ).On 0x4@11e5 thevalue x from the 
first node (at _rbx ) is compared against the value x of the second and if the 
first value is greater than or equal to the second the code jumps to @x4011lee 
that will update the value of rbx to point tothe next x value and also update 
the value of ebp that is then compared to see if we iterated over the entire list. 


So this iteration is checking that the x value of the current node is greater 
than or equal to the next x for all nodes in the list. If they are not the bomb 
explodes as we can see at 0x4011e9 . 


The other part of this function starting at @x4011f7 cleanups the stack frame 
for phase_6 and returns. 


Now that we saw everything that this function is doing we know that our input 
numbers are used to sort the linked list in descending order. 


Don't forget that before being used to reorder the list each input number will 
be changed to abs(n-7) . 
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The values of each node are: 


node# x (hex) x (dec) 


1 @x14c 332 
2 @x0a8 168 
3 @x39c 924 
4 Qx2b3 691 
5 @x1dd 477 
6 Qx1bb 443 


The values of x for the final list must be in the following order: 


924 -> 691 -> 477 -> 443 -> 332 -—> 168 


Which means the list must be reordered as: 


node3 -> node4 -> node5 -> node6 -> nodel -—> node2 


Then the solution for this phase is: 


432165 
Congratulations! You've defused the bomb! 


Finally! The bomb has been defused! 


Or not? There's something odd in the C file. The main function ends like this: 


input = read_line(); 
phase_6(input); 
phase_defused(); 


/* Wow, they got it! But isn't something... missing? Perhaps 
* something they overlooked? Mua ha ha ha ha! x/ 


return Q; 
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Defusing a binary bomb with gdb 
- Part 7 


This post is part of a series where I show how to defuse a binary bomb by 
reading assembly code and using gdb . You might want to read 


part if you haven't yet. 


This is it. We are finally in the last post of the series. 


In the last post the bomb was defused but there was something odd in the C 
file. This was the end of the main function: 


input = read_line(); 
phase_6(input); 
phase_defused(); 


return Q; 


And I left a hint in the last post about a call toa secret_phase function from 
phase_defused . 


401630: e8 Od fc ff ff callq 401242 <secret_phase> 


phase_defused isa function that is called every time a phase is defused so let's 
take a look at it: 


Q0000000004015c4 <phase_defused>: 
4015c4: 48 83 ec 78 sub $0x78,%rsp 
4015c8: 64 48 8b 04 25 28 00 mov %FS:0x28,%rax 
4015cf: 02 00 
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4015d1: 
4015d6: 
4015d8: 


# 603760 


4015df: 


4015e1: 
4015e6: 
4015eb: 
4015f0: 
4015f5: 
4015fa: 


t> 


4015f Ff: 
401602: 


401604: 
401609: 
40160e: 
401613: 
401615: 


401617: 
40161c: 
401621: 
401626: 
40162b: 
401630: 
401635: 
40163a: 
40163f: 
401644: 
40164b: 
40164d: 


40164f: 


lt> 


401654: 
401658: 
401659: 
40165a: 
40165b: 
40165c: 
40165d: 
40165e: 
40165f: 


31 


cO 
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48 89 44 24 68 


83 3d 81 21 20 00 06 
<num_input_strings> 


75 


Ac 
48 
48 
be 
bf 
eg 


83 
75 


be 
48 
eg 
85 
75 


bf 
e8 
bf 
eg 
b8 
eg 
bf 
e8 
48 
64 
00 
74 


eg 


5e 


44 
4c 
54 
26 
38 
5 


Q3 


26 
7C 
fd 


24 
4 
25 
4 
00 
fc 
25 
4 
44 
33 


f4 


c4 


24 
24 


40 
24 


tT 


78 


00 
10 


tf 


28 00 


mov 
xor 
cmp l 


jne 


lea 
lea 
lea 
mov 
mov 
callq 


cmp 
jne 


mov 
lea 
callq 
test 
jne 


mov 
callq 
mov 
callq 
mov 
callq 
mov 
callq 
mov 
xor 


je 
callq 


add 
retq 
nop 
nop 
nop 
nop 
nop 
nop 
nop 


%rax, 0x68(%rsp) 
%eaXx , 6CAaX 
$0x6 , @x202181(%rip) 


40163f <phase_defused+@x7b 


0x10(%rsp) ,%r8s 
Oxc(%rsp) ,%*rcx 
QOx8(%rsp) ,%*rdx 
$0x402619,%esi 
$0x603870,%edi 
4Q00bfO <__isoc99_sscanf@pl 


$0x3,%eax 
401635 <phase_defused+@x71 


$0x402622,%esi 

0x10(%srsp) ,%rdi 

401338 <strings_not_equal> 
%eaXx , 6CAX 

401635 <phase_defused+0@x71 


$0x4024f8,%edi 

400b10 <puts@plt> 
$0x402520,%edi 

400b1@ <puts@plt> 
$0xO, eax 

401242 <secret_phase> 
$0x402558,%edi 

400b10 <puts@plt> 
0x68 (%rsp) ,%rax 
%FS:0x28,%rax 


401654 <phase_defused+0x90 
400b30 <__stack_chk_fail@p 


$0x78,%rsp 


The first few lines until 0x4015d8 are for setting the stack protectoril and then 
saving rax beforesettingitto @ on 0x4015d6 .Thenon 0x4015d8 it 
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compares if we already went through all the six phases by looking at the number 
of input strings. This comparison will only be true after defusing the six phases 
so before the last post the code always jumped to 0x40163f that restored the 
value of rax and checked the stack protector before returning. 


Now that the sixth phase was defused the code will continue on @x4015e1 . In 
the next three lines, registers r8 , rcx and rdx will store addresses to hold 
local variables and then on @x4015f@ and 0x4015f5 , esi and edi receive 
two addresses. Let's look at them to see what is in each address: 


(gdb) p (char *) 0x402619 

$1 = @x402619 "%d %Sd %s" 

(gdb) p (char *) 0x603870 

$2 = 0x603870 <input_strings+240> "1 Q" 


How could I guess they were strings? Look at the next line: 


4015fa: e8 f1 f5 ff ff callq 400bf®@ <__isoc99_sscanf@plt> 


sscanf_ has the following signature: 


int sscanf(const char x*str, const char xformat, ...); 


Both edi and esi areused to hold the first and second arguments, 
respectively. Then the only thing that both registers could store were addresses 


pointing to strings~. 


The value 1 0 on edi looks familiar? It should, because that is the answer 


for the [J 


sscanf is then used to scan the input of the fourth phase again but with a 
different format now, expecting a string after the second value. You can see that 
on 0x4015ff ifit doesn't see 3 values itjumpsto @x401635 that will print the 
following message and return: 


(gdb) p (char *) $edi 
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$3 = @x402558 "Congratulations! You've defused the bomb!" 


Otherwise this function will compare if we entered the correct string to activate 
the secret phase. Looking at the instruction on @x401604 we can see what is 
the address of the activation string: 


(gdb) p (char *) 0x402622 
$4 = 0x402622 "DrEvil" 


If the input for phase 4 includes DrEvil atthe end the code will then call the 
secret phase on 0x401630 : 


401630: e8 Od fc ff ff callq 401242 <secret_phase> 


Now we know how to get to the point of calling secret_phase . Let's take a 
look at the code for it: 


Q000000000401242 <secret_phase>: 


401242: 53 push ‘%rbx 

401243: e8 56 02 00 00 callq 40149e <read_line> 
401248: ba 0a 00 00 00 mov $Oxa, *edx 

40124d: be 00 00 00 00 mov $0xO,%esi 

401252: 48 89 c7 mov %rax,%*rdi 

401255: e8 76 f9 ff ff callq 40@bd@ <strtol@plt> 
40125a: 48 89 c3 mov %rax,%*rbx 

40125d: 8d 40 ff lea -0x1(%rax) ,%eax 
401260: 3d e8 03 00 00 cmp $0x3e8 , seax 

401265: 76 05 jbe 40126c <secret_phase+@x2a> 
401267: e8 ce 01 00 00 callq 40143a <explode_bomb> 
40126c: 89 de mov %ebx,%*eS1 

40126e: bf f@ 30 60 00 mov $0x6030f0,%edi 

401273: e8 8c ff ff ff callq 401204 <fun7> 

401278: 83 f8 02 cmp $Ox2 ,%eax 

40127b: 74 05 je 401282 <secret_phase+0x40> 
40127d: e8 b8 01 00 00 callq 40143a <explode_bomb> 
401282: bf 38 24 40 00 mov $0x402438,%edi 

401287: e8 84 f8 ff ff callq 400b10 <puts@plt> 
40128c: e8 33 03 00 00 callq 4015c4 <phase_defused> 
401291: 5b pop %rbx 

401292: c3 retq 

401293: 90 nop 

401294: 90 nop 


http://webcache.googleusercontent.com/search?q=cache:aW_YFEmXe2cJ:blog.carlosgaldino.com/2016/05/24/defusing-a-binary-bomb-with-gdb-part-7.html+... 4/11 


5/29/2016 


401295: 
401296: 
401297: 
401298: 
401299: 
40129a: 
40129b: 
40129¢c: 
40129d: 
40129e: 
40129f: 


After reading the input for this secret phase on 0x401243 , edx will store the 
value 10, esi willstore NULL and rdi will store the input we gave. Then 
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nop 
nop 
nop 
nop 
nop 
nop 
nop 
nop 
nop 
nop 
nop 


strtol a will be called on @x401255 and judging by the values on the 


registers it means our input will be converted to a number in base 10. After that, 


on 0x40125a_ the already converted number will be stored on rbx .On 


Q@x40125d_ the value will be modified by subtracting 1 and placed again on 


eax . Then acomparison against 0x3e8 whichis 100@ in base 10. If our 


input islessthan 1000 the code willjumpto x40126c to continue and if not 


the bomb will explode. 


At 0x40126c ourvalue is placed on esi and edi gets an address. Both 


values will be used in the next function fun7 thatiscalledon @x401273 .The 


result that fun7 mustreturnis 2 asyoucanseeon 0x401278 . 


Before looking at fun7 let's look at what is in the address that edi received 


and is used as the first argument for fun7 : 


(gdb) x Qx6030fO 


Qx6030f@ <n1>: 


0x00000024 


Hmm, n1 . This name doesn't give any clues about what exactly this is. Let's 
look at fun7 then: 


0000000000401204 <fun7>: 
401204: 
401208: 
40120b: 
40120d: 
40120f: 
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48 83 ec 08 
48 85 ff 

74 2b 

8b 17 

39 f2 


sub 
test 
je 
mov 
cmp 


$0x8, srsp 
%rdi,%*rdi 

401238 <fun/+0x34> 
%rdi) ,%edx 
%eSi1,%*edx 
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401211: 7e Od jle 401220 <fun7+@x1c> 
401213: 48 8b 7f 08 mov Q@x8(%rdi),%*rdi 
401217: e8 e8 ff ff ff callq 401204 <fun7> 
40121c: Q1 cO add %eax , *eaX 

40121e: eb 1d jmp 40123d <fun7+0x39> 
401220: b8 00 00 00 00 mov $0x@,%eax 

401225: 39 f2 cmp %eS1,%edx 

401227: 74 14 je 40123d <fun7+0x39> 
401229: 48 8b 7f 10 mov Qx10(%rdi) ,%rdi 
40122d: e8 d2 ff ff ff callq 401204 <fun7> 
401232: 8d 44 00 01 lea Qx1(%rax,%rax,1) ,%eax 
401236: eb @5 jmp 40123d <fun/7+0@x39> 
401238: b8 ff ff ff ff mov SOxffttffff,seax 
40123d: 48 83 c4 08 add $0x8, srsp 

401241: c3 retq 


It first checks whether rdi is NULL ( @x@ ) and if it is the function will return 
the value -1 ( Oxffffffff at 0x401238 ). If not, the value stored in the 
address rdi is storing will be placed on edx and then compared (on 

Qx40120f ) with our input number. If the value on edx is less than or equal 
to our number the code goes to 0x401220 , if not it continues on @x401213 . 
Let's continue on @x401213 then we come back to see what happens in the 
other branch. 


On 0x401213 rdi will store whatever is 8 bytes after the address already on 
rdi andcall fun7 again. 


In the other branch, when the number on edx is less than or equal to our 
number, the code goes to @x401220 thatsets eax to @ , compares what is 
on edx with our number and if they are equal it goes to @x40123d that 
returns. If the numbers are different then the instruction at @x401229 will 
change rdi to store whatever is 16 bytes after the current address it has and 
then call fun7 as the other branch does. 


In each branch rdi is changed to hold the new address located either 8 or 16 
bytes after its current address. The first thing that rdi holds is anumber, the 
other two are pointers, so this might be a binary tree: 


struct node { 
int data; 
struct node xleft; 
struct node xright; 


http://webcache.googleusercontent.com/search?q=cache:aW_YFEmXe2cJ:blog.carlosgaldino.com/2016/05/24/defusing-a-binary-bomb-with-gdb-part-7.html+... 6/11 


5/29/2016 Defusing a binary bomb with gdb - Part 7 - carlosgaldino 


i 


The root node, located at the initial address that fun7 is called with is the 
following: 


(gdb) x @x6030f0 

Qx6030f®@ <n1>: Q0x00000024 
(gdb) x 0x6030f0+0x8 

Qx6030Ff8 <n1+8>: 0x00603110 
(gdb) x 0x6030f0+0x10 

@x60310@ <n1+16>: 0x00603130 


After following the node pointers we can see that the tree structure is the 


following: 
Ox24 
ig Oa 
On® Ox3 2 
we “ay A Sy 
Ox2D 
Orb Oxib 
yi he aS f A ou 
Oxt OW Oxi4 Qx23 x28 Ox2F OxéS 


We know how the tree is structured but we don't know what we need to do to 
get to the right answer. secret_phase calls fun7 and expects it to return the 


value 2: 
401273: e8 8c ff ff ff callq 401204 <fun7> 
401278: 83 f8 02 cmp $Ox2 ,%eax 
40127b: 74 05 je 401282 <secret_phase+0x40> 
40127d: e8 b8 01 00 00 callq 40143a <explode_bomb> 
401282: bf 38 24 40 00 mov $0x402438, edi 
401287: e8 84 f8 ff ff callq 400b10 <puts@plt> 
40128c: e8 33 03 00 00 callq 4015c4 <phase_defused> 
401291: 5b pop %rbx 
401292: c3 retq 


So let's see what fun7 returns. We know it is a recursive function. Let's see 
what is the base case, which are actually two: 
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401208: 48 85 ff test %rdi,%*rdi 

40120b: 74 2b je 401238 <fun7+0x34> 
And: 

401225: 39 f2 cmp %eS1,%edx 

401227: 74 14 je 40123d <fun7+0x39> 


Both show that the function returns when we reached a NULL pointer (first 
case) or if the number we gave is equal to the one in the current node (second 
case). 


But in the first case the code jumps to @x401238 that sets the return value to 


—1:; 
401238: b8 ff ff ff ff mov SOxtttttftf, sceax 
40123d: 48 83 c4 08 add $0x8,%rsp 
401241: c3 retq 


The second case jumps straight to @x40123d but before comparing the 
numbers it sets the return value to @ at 0x401220 : 


401220: b8 00 00 00 00 mov $0xO,%eax 
401225: 39 f2 cmp %eS1,%edx 
401227: 74 14 je 40123d <fun7+0x39> 


So if we provide a number that is not present in the tree the code will reach a 
NULL pointer and return -1 andif our number is present it willreturn 2Q . 


Now we need to look at each recursive call to fun7 and see what the current 
call will do with the result from the inner call. Let's see what happens after the 
inner fun7 call returns: 


40120f: 39 f2 cmp %eS1,%edx 

401211: 7e Qd jle 401220 <fun7+@x1c> 
401213: 48 8b 7f 08 mov x8 (%rdi) ,%rdi 
401217: e8 e8 ff ff ff callq 401204 <fun7> 
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40121c: 01 cO add %eax , %eAX 
40121e: eb 1d jmp 40123d <fun7+0x39> 


This is the case when our number is smaller than the current node value. It 
simply doubles the return value (on @x40121c )andjumpsto @x40123d to 
return. 


In the other branch, when our number is greater than or equal to the current 
node value it goes to 0x401220 : 


401220: b8& 00 00 00 00 mov $0xO, seax 

401225: 39 f2 cmp %eS1,%edx 

401227: 74 14 je 40123d <fun/7+0x39> 
401229: 48 8b 7f 10 mov Qx10(%rdi) ,%rdi 
40122d: e8 d2 ff ff ff callq 401204 <fun7> 

401232: 8d 44 00 01 lea Qx1(%rax,%rax,1) ,%eax 
401236: eb 05 jmp 40123d <fun7+0x39> 


Here if the values are equal the function will return @ as we saw earlier but if 

they are different, fun7 will be called again and the return value from the 

inner call will be doubled as in the other branch but in this case it will also add 
1 toit: 


401232: 8d 44 00 01 lea Qx1(%rax,%rax,1) ,%eax 


Although lea means load effective address this instruction is often used 
for arithmetic operations and that's exactly the case here. The instruction 
above means: 

eax = 1 * rax + rax +1 
Simplifying: 


eax = 2*xrax + 1 


Which then leads us to the following code for fun7 : 
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int fun7(node *n, int value) { 
if (n == NULL) { 


return -1; 
} 
if (n->data <= value) { 

if (n->data == value) { 

return Q; 

} 

return 2 * fun7(n->right, value) + 1; 
} else { 


return 2 * fun7(n->left, value); 


} 


Looking again at the tree structure we can try to guess which value will provide 
the correct answer by visiting the correct nodes. 


Ox24 
a eee Nt os 
On¥ O32 
—“— A oe 
Oxi6 2D 
any, ¢ P, fs, 
Oxt Ox") OxL4 QOx23 Ox28 Ox2F Oxéd 


One option is to visit @x8 and 0x16 . Replacing the node addresses with the 
actual data they have we would have the following callsto fun7 : 


return fun7(0x24, 0x16); // from ‘secret_phase’ 
return 2 * fun7(0x8, 0x16); 
return 2 * fun7(0x16, ®x16) + 1; 
return Q; 


That will give the right answer: 


Curses, you've found the secret phase! 

But finding it and solving it are quite different... 
22 

Wow! You've defused the secret stage! 
Congratulations! You've defused the bomb! 
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There is another possible answer for this phase and finding it ts left as an 
exercise to the reader. 


Notes 


1. Assuming this is a correct program. e 


2. https://en.wikipedia.org/wiki/Buffer_overflow_protection 


3. For more information about strtol : http://man7.org/linux/man- 


long int strtol(const char xnptr, char xxendptr, int base); 


The strtolQ function converts the initial part of the string in nptr to a 
long integer value according to the given base, which must be 
between 2 and 36 inclusive, or be the special value o. 


4. If you want to learn more about lea , its difference with mov , how and 
why arithmetic operations can be performed with lea you can start by 
reading the following page: 


http://webcache.googleusercontent.com/search?q=cache:aW_YFEmXe2cJ:blog.carlosgaldino.com/2016/05/24/defusing-a-binary-bomb-with-gdb-part-7.html... 11/11 


